Java and . NET - Integration vice of Interoperability ( the new approach to Java / . NET integration with JNI )

This paper is aim to contradict Microsoft’s and SUN’s announcement that JavaOne project will solve Java/.NET interoperability problem and to propose a new approach to Java/.NET integration with JNI . JavaOne project can be used in some class of projects related to network systems like J2EE, Web applications, communications between modules in different OS, etc. But when Developer wants to integrate Java and .NET modules as one application use of some network communications between Java and .NET modules with mediators (SOA, Messaging, etc.) in one process is cumbersome, inefficient and with huge overhead. In this case a better solution is use of Java Native Interface as only means for direct integration Java and .NET in one process. In this way you can write code in a .NET language (C#, MCpp, J#, VB) that interface directly and fast with .NET environmet, you need not use expensive server software or third-party bridges, JNI coding can be easy automated with special tools that can save huge costs for such software development. Approaches to Java/.NET Interoperability Java and .NET are two powerful technologies that used by companies for development different type of software. The problem is that most of companies have legacy applications/systems developed with Java and with .NET. And they faced with the problem: How to incorporate the software they use. On April 21, 2004, Sun Microsystems and Microsoft realized that they need joint collaboration in improving interoperability between Java and .NET products. They announced development of Java/.NET Interoperability Technology (IT). I guess that in that time the sense of “interoperability” was not perfectly clear to them. Nowadays “interoperability” has different realization in software technologies. We can find several approaches of interoperability implementations as follows: • Web Service Interoperability • Resource (or data) interoperability • Java/.NET Bridging • Java/.NET integration with JNI Besides these I want to note some approaches that are called as interoperability: Java-to-.NET or .NET-to-Java source code migration (conversion) and Joining Java and .NET technologies into the single system, e.g. all the source code (Java and .NET) compiled into CLR. These approaches are the worst that could be imagined. Java-to-.NET or .NET-to-Java source code migration (conversion) is actually re-development of legacy applications to Java and .NET through manual programming techniques (see, for example, http://msdn.microsoft.com/vstudio/java/migrate/workshop/default.aspx). “This is slow, costly and risky”, says Consultancy Northdoor. The example of Joining Java and .NET technologies into the single system is IKVM (see http://www.ikvm.net/). Beyond the fact that it violates MS and SUN licenses it makes ‘miracle’ interoperability/integration of Java and .NET. Web Service Interoperability Technology WSIT is a key component of the internal project code-named "Tango" and part of the ongoing web services interoperability efforts between Sun and Microsoft. "Microsoft is committed to interoperability between the Windows Communication Foundation and the Java platform. “The work that Sun is doing with its WSIT project and our collaborative engineering efforts over the past year are tangible evidence that the web services specifications, implemented by both companies, provide interoperability for our mutual customers," said Andrew Layman, director, Connected Systems Division Interoperability, Microsoft. "Sun is committed to open source and will continue to promote transparency of software development and technology standardization. By open sourcing the WSIT implementations, Sun is providing next generation web services technologies for the developer community to help build, deploy and maintain cross-platform composite applications for Service Oriented Architecture (SOA). This work is the result of extensive ongoing collaboration between Sun and Microsoft engineers and marks a major milestone in our relationship," said Rich Green, executive vice president, Software at Sun. This type of interoperability includes technologies that are delivered within the scope of open source efforts: • Quality of Service – WS-Reliable Messaging, WS-Coordination, WS-Transactions • Security – WS-Security, WS-Trust, WS-Secure Conversation, WS-Security Policy • Metadata – WSDL, XML Schema, WS-Policy, WS-Metadata Exchange • Messaging – SOAP, WS-Addressing, Message Transmission Optimization Mechanism (MTOM) The purpose of this interoperability type is supporting common protocols and means to interface Java and .NET systems (like J2EE, BizTalk, etc.) in MS Windows or other OS types. This approach is useful for development products based on existing WEB or Application Severs (e.g. composite applications). But it does not good enough in use of legacy Java and .NET codes used in development new products and standalone applications when embedding of Java-to-.NET or .NETto-Java needed. Resource (or data) interoperability There are two known resource interoperability: memory and database. Such interoperability implies availability of some mediator, which supports access to the common resource (memory, database). Memory interoperability The main idea of memory interoperability is one module writes to shared memory the other one on Notification gets the data and vise versa. This interface can be implemented in one process and between different processes in one computer. This type of interoperability does not allow asynchronous interface. Database Interoperability This is the same idea as above but instead of shared memory used some common database. This is a common solution and easy often easy implemented. The interfaces that permit each technology to access the underlying database can function independently from one another. This is certainly true in the case of J2EE access and .NET access. Their respective database connections are distinct from one another; each technology communicates with the database just as they do normally. The database includes tables, views, stored procedures, and supporting metadata. All of this is accessible by the .NET framework via ADO.NET. Likewise, these resources are accessible by the J2EE platform via JDBC. Each platform is able to access the database using standard API calls—in other words, you don't need to do write special code to achieve interoperability using this solution. Data is inserted, updated, deleted, and selected. When one platform modifies the data in some way, the other platform will see those modifications when it next requests data from the database. This kind of interoperability makes some common resources available to different modules written in Java and .NET. But in common Java module calls to .NET and vise versa are problematic.